1. Field of the Invention
The present invention generally relates to the field of visual programming languages and object-oriented programming languages and, more particularly, to managing programming object visual representations participating in alternative execution paths.
2. Background Description
The use of state reflection in visual programming, as described in copending application Ser. No. 09/409,277, is a novel idea not found in the state of the art in visual programming. For the most part, visual programming languages fall into the following categories:
Visual Designersxe2x80x94These are visual programming languages, which focus on the construction of user interface applications. Much of the focus is on interface form and presentation construction with caveats for generating event code to facilitate textual programming of other parts of an application.
Wiring-Based Languagesxe2x80x94These languages have visual representations of programming entities, such as objects or processes. Programming proceeds by creating and connecting visual representations with lines, which typically indicate data or event flow.
Structured-Logic Basedxe2x80x94These focus on structuring the logic of a program. Typically logic is represented with nested graphical figures which represent logical entities, e.g. if, loops, etc. Typically visual representations of programming objects are not shown in these tools.
Form-Basedxe2x80x94These are visual programming languages of the spreadsheet genre. Typically represented as grids or arrays of numbers, a textual macro language typically accompanies the language to do more complex manipulations.
The visual programming approach found in copending application Ser. No. 09/409,277 strongly identifies a programming artifact, also known as a programming object, such as a variable, or data structure, with its visual representation. It furthers the state of the art in visual programming by defining a programming state, also known as a usage state or semantic state, for these artifacts and reflects this state visually in the visual representation of the programming object. From a sequential programming viewpoint, the semantic state of a programming object at a given point of a program indicates statically analyzed properties of a programming object, as contrasted to run-time or execution-time values. Examples include xe2x80x9cthe variable x has been setxe2x80x9d or xe2x80x9cthe variable y has a non-negative valuexe2x80x9d. For a given programming object, the set of all possible states that could be assigned to it is called the semantic state space of the programming object.
For a programming object at a given point in the program, its semantic state information is presented to the user in a visually meaningful manner. In other terms, the program object""s visual presentation reflects how the programming object had been used and modified logically up to some specified point in the program, in the statically analyzed context of the entire program.
Conventional sequential programming provides a number of logical constructs that are problematic to this approach. These include the familiar, IF, CASE, WHILE, FOR, UNTIL programming structures. The first two cases, or CHOICE constructs, encompass multiple alternative logical or execution paths to be defined. The latter three my be categorized as LOOP constructs, which while they identify a single sequential path, in fact, identify a multitude of paths by way of iterations.
The difficulty that arises here is that each alternative logical path defines its own semantic state for each programming object, and in particular, at the end of each path, these alternative programming states of any one programming object need to be combined to one state, representing the total impact of the logical construct on each programming object. More concretely, for a variable xe2x80x9cxxe2x80x9d in an xe2x80x9cIFxe2x80x9d statement, if one path sets xe2x80x9cxxe2x80x9d and the other does not, the impact of the xe2x80x9cIFxe2x80x9d statement should be xe2x80x9cx may be setxe2x80x9d. Thus, the ideal solution is to produce for each programming object, a composite semantic state that is true across all alternatives, as in the example above, to represent the semantic impact of the logical statement on the programming object. This resolution of semantic state is the subject matter of this disclosure.
It is therefore an object of the present invention to provide a method and apparatus for maintaining programming artifact usage state, which in the context of multiple alternative coding paths, produces a converged state for those alternatives.
This invention builds on the disclosure of copending application Ser. No. 09/409,277. The basis of that disclosure is that programming objects have semantic usage state that can be represented visually. As programming proceeds during program editing, the usage state of the programming objects are reflected back to the visual representations. All of this happens at program editing time. By way of illustration only, if xe2x80x9cx=3xe2x80x9d were coded, the variable x would be set to green indicating it has been set to a constant.
This invention relates to an addition to the state reflection process relating to cases where the visual programming object participates in multiple execution paths. This would be the case, for example, if it were used in the TRUE and/or FALSE bodies of an IF statement. In this instance, the programming object""s usage state evolves differently in both paths. To proceed with this co-evolution of state requires a duplication of the programming object""s usage state on entry to the logical construct. The process of constructing a multiplicity of state replicas for alternative paths is called divergence. Ideally, at the end of the IF statement, the two states should be merged into a single usage state on the programming object, before proceeding. This invention specifies processes for managing these alternative states, as well as provisions for merging states, a process called convergence. This approach is useful in providing a single state, reflecting prior use and logical modification up to any point in the program, including the impacts of alternative execution paths induced by logical constructs.